the canceled job (marking the PR as failure) is unrelated to the PR change.

Any chance to have it reviewed please?
Apache pool of GitHub actions runners is shared across all Apache projects. During the last weeks, the limits was often reached causing jobs to be queued. The intent of this PR is to reduce the load to limit the queue time.

Anyone can review please?

Currently there are several jobs in the queue and just for last few hours and looking at a single PR checks we could have saved several hours of compute time (see https://github.com/apache/paimon/actions/workflows/e2e-tests-flink-2.x-jdk11.yml and look for same branch triggered several times in few minutes between them)

trying by mentioning some of the most active contributors to have more chance that it is noticed as i think that given it is impacting a bit all Apache projects using GitHub actions, this is important enough:
@JingsongLi @XiaoHongbo-Hope @leaves12138

Thanks for filling in the missing concurrency configs!

The concurrency pattern is inconsistent across this PR: utitcase-jdk11.yml uses cancel-in-progress: true while the other 4 files use cancel-in-progress: ${{ github.event_name == 'pull_request' }}. Also, e2e-tests-flink-1.x.yml already had a
working concurrency block

The concurrency pattern is inconsistent across this PR: utitcase-jdk11.yml uses cancel-in-progress: true while the other 4 files use cancel-in-progress: ${{ github.event_name == 'pull_request' }}

When the workflow can be triggered only by pull_request event, I proposed a simplified value for cancel-in-progress.
Do you prefer to align to use the same concurrency pattern or keep as proposed?

Also, e2e-tests-flink-1.x.yml already had a
working concurrency block

this one I changed it to align with other concurrency declaration.
Do you prefer to keep this one not aligned with other concurrency pattern or to align it?